Web3 Project Analysis Plan
The dedicated Paragraph channel for the Web3 Project Analysis Series is:
Plan Overview
After a few days of experimentation, I believe that the Web3 Project Analysis Plan is a meaningful endeavor. I’m not sure whether readers gain much from the analysis articles, but from my own perspective of understanding projects and learning technology, it’s been beneficial. So I need to keep this plan going and make it a routine.
The specific plan is to analyze one Web3 project per week, starting from reading the whitepaper, to understanding the project’s operational model and current business status, with a particular focus on the technical philosophy and innovation. Then, I’ll write an analysis report—not a professional one, more like study notes. The projects chosen for analysis will be subjectively selected. The final report may be of high quality and insightful, or it may be short and lack substance. After all, I can’t know in advance whether a project is worthwhile, especially from a technical perspective.
Engineering Code Has No Value
This plan is more like what a blockchain researcher would do, rather than what a blockchain developer should be doing. So why not write 100 lines of code daily to develop a blockchain tool, or build up a large blockchain project incrementally?
Because engineering code without a project context is worthless. I’ve written a lot of code over the years, but if I look back at that code now, it’s meaningless. Engineering code is often written to improve the functionality of a specific project, which in turn serves business and promotional needs. Without the business context, the code is meaningless.
Especially with the growing power of AI, writing engineering code is becoming increasingly cheap. AI can generate tens of thousands of lines of code in minutes—it far exceeds human capabilities in code output. If I rely on writing hundreds of lines of code daily to improve myself, I will fail miserably. So I won’t do that.
What kind of engineering code is meaningful? Code written to implement functionality after identifying a clear product requirement and positioning—then let AI do the heavy lifting. AI-generated code may sometimes go off track and need manual debugging. In such cases, manually written engineering code is meaningful. That’s the pace of development today.
In the past, people liked to say, “Talk is cheap. Show me the code.” But times have changed. Now prompts are more valuable than code. Maybe the new saying should be, “Code is cheap. Show me the prompt.”
Writing Better Expresses Ideas
Another reason I don’t plan to write engineering code daily is that I’ve already tried creating small blockchain tools and large blockchain projects. So far, those ideas haven’t produced results. Maybe the demand simply doesn’t exist. With no positive feedback, it’s impossible to keep going.
Compared to code, writing—articles, ideas—is more meaningful. A product idea might require 100 lines or 10,000 lines of code. The time investment is vastly different, but if the attention it gets is zero, then the result is the same. The extra 9,900 lines of code were written in vain. But writing can convey thought.
You might argue, “How can engineering code be worthless?” Take Ethereum clients, for example—the same spec has five or six implementations in different languages with different optimizations and varying market share. Isn’t that a testament to the value of engineering code? Of course it is. These teams are sponsored by the Ethereum Foundation, running companies, and working on established projects. Their engineering code is definitely valuable. I’m referring to code without a project context.
Although engineering code lacks value in this sense, educational code still has meaning. I still review exercises from computer science courses to maintain my coding skills. I’m now on my third round of doing those exercises. This time, I strictly limit myself to solving one problem a day. This ensures enough time to digest the knowledge and trust the power of the subconscious. It also lets me allocate time to other things, instead of endlessly doing the same problems. Since the pace is slow, I can gradually build the habit of daily practice and keep from forgetting what I learned in class.
Enhancing Macro Understanding
Why do I think project analysis is meaningful? Because much of my understanding of blockchain tech came from reading a lot of whitepapers years ago. Back then, I downloaded the whitepapers of the top few hundred coins by market cap and even printed them out on A4 paper to read.
I remember someone once emailed me asking how to learn blockchain technology. I wrote a detailed reply explaining where I downloaded whitepapers and what books I read. They later responded saying that wasn’t what they were looking for—they wanted to learn how to write code. That’s when I realized people define “technology” differently.
Before AI, I didn’t appreciate the value of code. Now that AI exists, I still don’t.
The Importance of Research Skills
In crypto, people often say DYOR (Do Your Own Research). It’s frequently used by KOLs when promoting or endorsing a token to declare that it’s not investment advice—you’re responsible for yourself. “Research ability” has always been crucial. Without it, you can’t even manage your own money. In fact, everything requires research: learning English, job hunting, planning vacations, writing code, studying science, making your girlfriend happy—it’s all research. The goal of the Web3 Project Analysis Plan is to research projects and train research skills.
People with strong research skills can learn anything more easily. Think about it—how long does it take to figure out how to write decent code, especially routine code for work? Often it doesn’t even require “research”! So, if someone can master a technical concept through research, they definitely have the ability to learn how to write code.
So why do I think I can write analysis reports? I haven’t written many before, but I have done some horizontal comparisons of projects based on tech. Focusing on analyzing one project’s technology shouldn’t be difficult. For projects I’ve worked on, I could definitely write about the details—though I can’t because they’re still active. Writing project analyses is also a process of learning and accumulating.
In fact, I outlined my methodology for analyzing blockchain projects a while ago in this article: Understanding the Technical Architecture of Any Blockchain Project. I still think that article holds up—it’s all about on-chain and off-chain interactions, and different projects just plug in different business logic.
Choosing a Writing Platform
I’ve been torn about what kinds of articles should go on my blog. I don’t want to clutter the blog with “Analysis of Project XX” posts. To keep the blog list clean, I decided to post this series on another platform. Recently I found Paragraph quite nice. Paragraph is a Web3-focused newsletter platform, similar to Substack in Web2. Every article is permanently stored on the Arweave blockchain, including the author’s name, avatar, content, images, etc. (This also means once published, the article can’t be deleted.)
Why not use other platforms like Zhihu, Juejin, or even Toutiao, Baidu, Denglian, or platforms like Medium, X, Mirror? Those platforms would definitely get more views and followers.
Because platforms filled with low-quality content are not worth posting high-quality articles on. The users there wouldn’t even understand what I’m writing. Just look at the Juejin homepage—8 out of 10 articles are about Cursor. Hard to imagine the user base being any good. Zhihu is even worse—chaotic, commercialized, and full of popups asking you to log in or download the app. Who seriously uses those sites? On Maimai’s anonymous board, I’ve posted thousands of comments, getting tens of millions of views—mostly provocative and controversial. Do those views mean anything? No.
So, just keep working. Once I become somebody, then I can worry about traffic. Nobody cares what a nobody writes.
Why Make a Plan
If it were up to my personal preferences, the most valuable articles I’d write would be rants about coworkers, companies, and interview experiences. Those pieces contain personal experiences, real emotions, and hard-earned insights—far more interesting than technical posts. My views on the industry, complaints about the company, and rants about colleagues are things that AI can never replicate, because AI has no emotions. It doesn’t get angry or frustrated. AI can instantly generate tons of content on technical topics, but it will never understand human feelings.
After all, everyone has to make choices: either get busy living or get busy dying.
